Conventionally, request messages from client systems to processors may be sent through an intermediary server. The intermediary server may receive request messages from the client systems in a format particular to each respective client system. Each request message may identify a particular processor to process the request. To effectively communicate the request message to the particular processor, the intermediary server may have to reformat the request message from the format used by the client system into a format used by the particular processor. In other words, the intermediary server must know how to communicate with both the client system and the processor according to their particular formats.
On a large scale, such processing and reformatting of request messages is cumbersome, inefficient and expensive. For example, the intermediary server may wish to communicate with thousands of different client systems, each communicating in its own respective format, and hundreds of different processors, each communicating in a different format. It may be desirable for the intermediary server to be capable of communicating with as many different processors as possible, as they may each offer different combinations of request processing services to the client systems. Thus, the intermediary server must be capable of translating request messages across millions of client system-processor combinations.
To achieve this, the intermediary server must invest heavily in building, upgrading and maintaining connections with hundreds of different processors around the world. Each connection requires product development, quality assurance and product operations effort. These connections are not scalable because all of the processors have their own technical and functional specifications that the intermediary server must build to. This hinders the intermediary server from scaling up because each connection requires effort and investment.